Important: Unless otherwise specified, all information in this chapter applies to both Sun Solaris- and Red Hat Enterprise Linux-based WEM systems.
Important: If you are uninstalling WEM in any clustered setup prior to an upgrade, the node has to be put into maintenance mode first (i.e. removed from the resource group). This ensures that all the processes running on this node are stopped and prevents the active node from failing over to become the standby node. For more information on this procedure, please refer to WEM High Availability Redundancy with Cluster Application in the appendices. |
•
|
All data files, typically located in the /<ems_dir>/server/data directory and all subdirectories residing there (i.e. /bulkstats, etc.).
|
|
•
|
PostgreSQL data files, located in the ~postgres/data or users/postgresx.x.x/data directory. Refer to the Backing-up WEM Databases section of the WEM Database Maintenance chapter in this guide for more information.
|
Important: Downgrading the WEM application to an earlier version is not supported at this time. You must uninstall the current version and install the older version using the instructions located in Installing the WEM Software chapter of this guide. Please contact your local sales representative for information on preserving data stored by the current WEM instance prior to uninstalling.|
•
|
GUI-based method: This method is the most often used uninstallation procedure. Requirements for using this method include:
|
Important: If the uninstall GUI does not open, add X-windows port (TCP/6000) in the exception list of Windows firewall.|
•
|
Console-based method: This method is available to users who do not have an X-Windows client available for remote network connectivity to the WEM server via Telnet or SSH.
|
Important: The GUI-based uninstall script is designed to protect all the historical data files that are currently in use. However, it is still recommended that you manually perform a backup of these files before continuing.|
Step 1
|
|
Step 2
|
Go to the directory in which WEM is installed (the /users/ems directory by default) by entering the following command:
|
|
Step 3
|
Go to the /_uninst sub-directory by entering the following command:
|
|
Step 5
|
Click the Next button. A dialog appears identifying the processes to be stopped.
|
|
Step 6
|
Click Next and follow the on-screen instructions.
|
|
Step 7
|
Click Finish to complete the uninstallation process.
|
The uninstall script leaves the /ems directory in place with several sub-directories.
|
Step 8
|
Optional: If all critical and historical data files have been properly backed up, delete the /ems directory using the following commands:
|
Important: If you decided to keep the /ems directory, it is highly recommended that at the very least you delete the _uninst directory. Failure to remove this directory before installing a new version of the WEM application using the GUI-based installation method will result in a different _uninst directory being created each time you perform a software upgrade. This results in the creation of multiple uninstall directories (i.e. named /_uninst2, /_uninst3, etc.). The uninst file needed for the next uninstall would have to be located there.
Important: The console-based uninstall script is designed to protect all the historical data files that are currently in use. However, it is still recommended that you manually perform a backup of these files before proceeding with this procedure.|
Step 1
|
|
Step 2
|
Go to the directory in which WEM is installed (the /users/ems directory by default) by entering the following command:
|
|
Step 3
|
Go to the /_uninst sub-directory by entering the following command:
|
Upon completion, the uninstall script indicates that certain sub-directories were not deleted within the /ems directory.
|
Step 8
|
Optional: If all critical and historical data files have been properly backed up, delete the /ems directory using the following commands:
|
Important: If you decide to keep the /ems directory, it is highly recommended that at the very least you delete the _uninst directory. Failure to remove this directory before installing a new version of the WEM application using the GUI-based installation method will result in a different _uninst directory being created each time you perform a software upgrade. This results in the creation of multiple uninstall directories (i.e. named /_uninst2, /_uninst3, etc.). The uninst file needed for the next uninstall would have to be located there.Appendix A
Troubleshooting the WEM
Troubleshooting the WEM
In addition to the above, instructions are also provided for capturing client and server logs. These are provided in the Capturing WEM Client Logs and Capturing WEM Server Logs using Script sections of this appendix.
Important: Unless otherwise specified, all information provided in this chapter applies to both Solaris and Red Hat Enterprise Linux-based WEM systems.
|
|||||
|
|
Received “Unable to install Element Management System <version> over Element Management System: Installed product has newer version.” message when attempting installation.
|
|||
|
|
|
|||||||||||
|
|
|||||||
|
|
NOTE: The table name in the above message is after the 'FROM' keyword.
|
|
|
There is one workaround for this but there will be data loss for that mentioned counter. Manually drop the column from table to make the tables in sync. There is data loss only for that particular column. After this, restart all the bulkstat processes (bulkstatparser and bulkstatserver). After restarting, bulkstatparser will re-add that column in both the tables and data will be populated for that column.
|
|
Received “Could not connect to server, destroying applet” message.
|
|||||||||
|
|
Received “Java policy file is outdated or missing” message.
|
|||||
|
The .java.policy file is either missing from the user’s home directory on the client machine or it has expired.
|
|||||
 Important: All instances of the browser must be closed and restarted after the policy file has been updated. |
|
Received “Server could not establish connection with client, therefore notifications will not work.” message.
|
|||||
|
|
Check the configuration of the no limit ConsecutiveFailLogin parameter in the ua.cfg file (located in the <ems_dir>/server/etc directory by default). If users are frequently locked out due to reaching the maximum limit, you may consider increasing the limit, or disabling the functionality. You may also consider reducing the amount of time the account is locked out by modifying the configuration of the no locked out LockOutInterval parameter also contained in the ua.cfg file.
|
|
This is caused by the browser storing the.jar files for the newer version of the WEM client in its cache.
|
|
Check the java console and if you get exceptions like "Exception in thread "AWT-EventQueue-2" java.lang.NoClassDefFoundError", it could be the case that the browser cache is enabled on your workstation and needs cleanup.
|
|
|
|
Received “Callbacks between server and client are not working. Screen cannot be invoked.” message.
|
|||
|
|
|||||||||||
|
|
|||||||
|
|
Received “No matching data found” error when fetching bulkstatistics reports.
|
|||
|
|
|
 Important: If XMLFileType is set to 1, it will generate XML files irrespective of the other two mentioned configurables. |
|
Check if OverrideLastAccessFlag in bsserver.cfg is enabled. If it is enabled, disable it and restart the bulkstatserver.
|
|
|||
|
|||||||
|
|
|
|
|
|
When starting or stopping a WEM process, the user receives the error message ld.so.1: httpd: fatal: libgcc_s.so.1: open failed: No such file or directory.
|
|||||||
# crle –u –l $EMS_INSTALL_PATH/server/lib
|
|||||||
# cd /<ems_dir>/ems/server/lib
|
|
Update the.java.policy file on any client machine that uses JRE 1.6.0_24 and above with the following line:
|
|
An error message displays to update the.java.policy file when the user invokes the WEM url. This is typical with newer WEM builds.
|
|
|
Download the .java.policy file again from the options located on the WEM splash screen.
|
|
The WEM Process Monitoring dialog shows “Could not connect to server. Screen will not be invoked”.
|
|
|
Library=C:\Program Files\Java\j2re1.4.2_04\bin\jsound.dll
|
|
|
While manually upgrading from version 'A' to version 'B', if you use the migrate script from version 'A', the database will be backed up. However, to restore the database, you have to use the migrate script from version 'B', i.e., the script that is packaged with the version that you are upgrading to. You will get the latest migrate scripts for restoring the database after unpacking the lastest WEM install.xxx.tar.gz bundle. The reason for doing this is that the recent scripts are likely to be upgraded from previous versions.
|
|
Step a
|
Right-mouse click on the Java(TM) 2 Platform icon in the status area (Windows System Tray).
|
|
Step b
|
Select Open Console from the menu.
|
|
Step 3
|
Open the URL of the Web Element Management Server in the web browser, replacing img.html with imgdebug.html.
|
In the event additional troubleshooting assistance is required, debugging information can be collected using a script called getSupportDetails.pl. This script collects different log files and captures the output of certain system commands that aid in troubleshooting issues. This script is packaged with the WEM Server in the <EMS_INSTALL_DIR>/tools/supportdetails/ directory.
This script refers to an XML file to get the list of logs. This XML resides in the same directory as the script. Once executed, the script retrieves the contents of logs, files, folders, and output of certain commands and prepares a zipped file (/tmp/log/emssupportDetails.tar.gz), by default it is placed in /tmp/log directory.
|
Specifies the level of debug to run. It can have a maximum of 4 levels. The level 4 provides the most detailed information. Refer to README.txt file for more information.
|
|
|
Default: getSupportDetails.xml
|
|
|
Specifies the output directory for the emssupportDetails.tar.gz file if different from the default output directory (/tmp/).
|
|
Important: /etc/netmasks needs to be modified if the user is subnetting existing address and subsequently using a different network mask than the default one. If the netmask being used for a given IP address is a default one, then there is no need to modify this file.
Important: Cluster configuration is not supported on Cisco Red Hat Enterprise Linux (RHEL) operating systems for this software release (12.2).Web Element Manager must be installed on a minimum of two Sun Netra™ T5220 servers equipped with the hardware described in the Server Hardware Requirements section of this guide. We recommend a cluster installation restricted to two servers configured similar to that shown in the diagram below. The sample configurations in this appendix assume such an installation.
Important: Ensure you have installed the latest version of Oracle Solaris software and all appropriate software patches as described in the Operating System Requirements section.IPMP is a feature supported on Oracle Solaris. For more complete configuration information, refer to Configuring IPMP for WEM Server and also to the Oracle product documentation.
This section specifies the configuration changes required when installing WEM in Failover Mode rather than Standalone Mode when following the installation instructions in the Installing the WEM Software chapter. For this release, please use the GUI to perform the installation rather than the command line.
Important: Install and configure Web Element Manager in Failover Mode on both servers before configuring a cluster resource group.The following items are either different from, or prerequisites for, the installation steps defined in the Installing the WEM Software chapter:
|
•
|
|
•
|
The logical hostname and a floating IP address shared between the two nodes must be configured in /etc/hosts. Ems-Service is used as the logical hostname in the examples in the rest of this appendix.
|
|
•
|
Create the global disk path for a shared data directory, for example: /shareddir/ems-share.
|
Important: The following options are not set when installing in Failover Mode:|
•
|
WEM Service started by default and monitored by Process Monitor. (See the WEM Process Monitor chapter for more information on processes.)
|
Important: This process is configured on only one server in the cluster. It is reflected on both. Before clsetup can create a network resource for any logical hostname, that hostname and a common floating IP address associated with it must be specified in the /etc/hosts directory on both servers. This example uses ems-service as the logical hostname.
|
Step 1
|
|
Step 2
|
From the Main Menu select Option 2: Resource Groups.
|
|
Step 3
|
From the Resource Groups Menu, select Option 1: Create a Resource Group.
|
|
Step 4
|
When prompted to create a failover group, enter yes and select Option 1: Create a Failover Group. For this example, call the group ems-rg.
|
|
Step 5
|
When you are prompted to select a preferred server enter yes and enter the name of the Preferred server; for this example use Node1. Enter yes to continue the update.
|
|
Step 1
|
After the confirmation screen from the last task displays, press Enter to continue. Enter yes when prompted to add network resources.
|
|
Step 2
|
From the Network Resources Menu, select Option 1: Add a Logical Hostname.
|
If a failover resource group contains logical hostname resources, the most common configuration is to have one logical hostname resource for each subnet. Enter 1 to create a single resource.
|
Step 3
|
|
Step 4
|
Press Enter to continue. The screen displays:
|
clreslogicalhostname create -g ems-rg -p R_description="LogicalHostname resource for ems-service" ems-service
|
Step 5
|
Enter no when prompted to add any additional network resources.
|
|
Step 1
|
After the logical hostname confirmation screen, enter yes when prompted to begin adding data services.
|
|
Step 2
|
From the Data Services Menu select Option 1: EMSSCFO Server for Sun Cluster, and use the name ems-dsr for this example.
|
|
Step 3
|
Enter no when prompted to override the default.
|
|
Step 4
|
|
Step 1
|
After the completion confirmation screen, press Enter to continue. Enter no when prompted to add any additional data service resources. Enter yes when prompted to manage and bring this resource group online.
|
|
Step 2
|
The process is now complete. At this point you can enter the scstat command to display the current online/offline status if required.
Important: Network administrators are advised that they should have any connected clients log out at this time. If clients cannot reconnect after the upgrade, please refer to the Troubleshooting appendix for information on any Java-related errors.This can be confirmed either by a software switchover, or by running the scstat command to confirm the current node status.
|
•
|
|
•
|
Two Cluster Nodes: N-1 (initially this is the active node) and N-2 (initially this is the redundant node).
|
|
•
|
A Resource Group managed by Web Element Manager exists. ems-rg is used for this example.
|
|
•
|
A logical hostname and floating (shared) IP address has been configured on both servers. This example uses the default /etc/hosts folder. Use ems-service as the hostname for this example.
|
|
Step 1
|
Start with two server nodes: N-1 and N-2. They share both data files and database information. N-1 is currently active and N-2 is currently in standby mode, as shown below:
|
|
Step 2
|
With Web Element Manager running on N-1, put N-2 into maintenance mode (this is described in Removing an Inactive Node from the Resource Group below). Then upgrade WEM to version 12.0 or later.
|
At this point, the database is not yet updated. In cluster mode, when WEM is upgraded on N-2 the postgres database is not started. so a new DB schema is not created. This is because the schema will be updated through the currently active server N-1 with SQL scripts that are provided as part of the installation package; this is explained in the section Updating the Databases. At this point N-2 is still in maintenance mode but now with updated WEM software, and the database schema has now been updated as shown below:
|
Step 3
|
To prepare for the switchover, take N-2 out of maintenance mode.
|
|
Step 4
|
To upgrade WEM on N-1, bring N-2 back into the cluster and do a switchover from N-1 to N-2 so now N-2 is the active host and WEM starts running processes.
|
|
Step 5
|
Now place the formerly active node N-1 into maintenance mode and upgrade WEM software while N-2 is the active node as shown below:
|
|
Step 6
|
Once the upgrade is complete, N-1 can be switched back to its role of active node if necessary by using the Cluster commands, or N-2 can continue as the active node.
|
Important: Refer to the Installing the WEM Software chapter for more complete information about scripts and files. All configuration files placed in the <EMS_HOME>/server/etc folder and the script files in the <EMS_HOME>/server/scripts folder must be identical. This ensures that after the switch between servers, the behavior of EMS does not change in any way.Complete the following steps to remove N-2 from the Resource Group. Since the cluster resource group configuration will be same for both nodes, the cluster-related commands can be run on either node.
|
Step 1
|
Run the scstat command. scstat is used to verify the current status of the cluster resource group and ensures that on switchover/failover the servers will switch correctly. The following screen display reflects a properly configured cluster:
|
Important: N-2 must not be allowed to run any WEM processes. This prevents the secondary node from taking ownership of resources. Removing it from the Resource Group prevents a failover from happening and N-1 continues to behave like a standalone WEM thus ensuring a successful upgrade. To do this:|
Step 2
|
|
Step 3
|
From the Resource Groups menu, select Option 8: Change the Properties of a Resource Group.
|
|
Step 4
|
Enter yes when prompted to continue.
|
|
Step 5
|
|
Step 6
|
Select Option 1: Change the Nodelist Resource Group Properties
|
|
Step 7
|
|
Step 8
|
The nodelist now contains only N-1. When prompted to update the nodelist property, enter yes. If your update was successful you will see the following screen confirmation:
Press Enter to continue. You will receive confirmation that only N-1 remains in the nodelist. Select Option q to Quit and exit back to the Resource Group Menu.
|
Step 9
|
From the Resource Group Menu select Option s: Show Current Status to confirm the current network resources if required.
|
|
Step 1
|
Copy the sqlfiles.tar file from the N-2 installation to a folder on N-1 and untar the file. This process is described fully in the Installing the WEM Software chapter.
|
This will create a folder called sqlfiles.
|
Step 2
|
|
Step 3
|
|
Step 5
|
|
Step 6
|
Press Enter.
|
|
Step 7
|
Important: Currently, this is port 5432, but this may change in a later release.Complete the following steps to return N-2 to the Resource Group and take over resource ownership in order to upgrade the software on N-1.
|
Step 1
|
|
Step 2
|
From the Resource Groups Menu select Option 8: Change the Properties of a Resource Group.
|
|
Step 3
|
Enter yes when prompted to continue.
|
|
Step 5
|
|
Step 7
|
Select Option 1: Add a Node/Zone to the Top of the Nodelist.
|
|
Step 8
|
Select Option 1: N-2.
|
|
Step 9
|
Enter yes when prompted to update the nodelist property.
|
|
Step 10
|
|
Step 1
|
From the Resource Group Menu Select Option 5: Switch over a Resource.
|
|
Step 2
|
Scroll through the on-screen description and enter yes to continue.
|
|
Step 4
|
Select Option 1: Switch Group Ownership.
|
|
Step 5
|
Select the node to take ownership of ems-rg, which would be N-2. Enter yes to confirm. The screen will display the following message:
|
|
Step 6
|
|
Step 7
|
From the Resource Group Menu select Option s Show Current Status. This shows that N-2 is now online and N-1 is offline.
|
At this point return to Removing an Inactive Node from the Resource Group and begin the update process for N-1.
Important: Since the database schema were previously updated and both N-1 and N-2 share the same database, it is not necessary to run the SQL scripts again for N-1.Appendix C
WEM Configuration File Parameters
WEM Configuration File Parameters
This appendix provides information about the configuration file parameters pertaining to the Web Element Manager. WEM provides a number of configuration files which can be modified to fine-tune the operation of the application. These files are located in the /<ems_dir>/server/etc directory by default.
Important: Unless otherwise specified, all information in this chpater applies to both Sun Solaris- and RHEL-based WEM systems.
Important: This configuration file is customer-specific and is not operational without the appropriate license. Please contact your local sales representative for additional information.The following table describes the AUDIO file parameters.
|
The first field contains the severity level (number): The nth row in the SEVERITY section is n-1 in the fm.cfg file. Please use the fm.cfg file for the severity configuration information in detail.
The second field contains the audio file name. The audio files are present in the audio sub-directory in the client installation directory.
|
||
|
audioPlayedFor: This option will decide the priority of alarm to play an audio. The default value is 0.
|
||
The following table describes the TRAPAUDIO file parameters.
|
TRAPAUDIO: This section defines the mapping for Trap Number and the corresponding AUDIO file. This file is the default file to be played when the trap is received. If the filename field is kept empty then, the file associated with the severity of the trap will be played.
|
|
|
0: Disable - assume cumulative.csv will be available in <EMS ServerPath>/flash/blacklist/blacklist/
 Important: Do not change the value of configurable as functionality when this flag 0 is disabled |
||||
Important: Any change in the configuration files will restart the server resulting in client restart.
Caution: To ensure proper operation of the Web Element Manager, bulk statistic schema and formatting configuration in this file should not be altered.|
Schema: This section provides the schema format string for each subsystem. The parameter values in this section are internally used by the bulkstat server module and should not be changed.
|
||
|
Tolerance: These values indicate that the server will search records within a range (below and above the expected timestamp) if the exact record is not present. All values are in seconds.
|
||||
Important: Any change in the configuration files will restart the server resulting in client restart.
Caution: Several parameters contained in this file are configurable through the installation process.|
Directory: This section contains the directory path required for bulk statistics.
|
||||
|
If the specified directory does not exist, then the bulkstats files will be configured for FTPing in <serverpath>/data/.
 Important: The FTP directory path entry should always be an absolute path and not a relative path. |
||||
|
If the specified directory does not exist, then the bulkstats files will be configured for FTPing in <serverpath>/data/.
 Important: The FTP directory path entry should always be an absolute path and not a relative path. |
||||
 Important: The Archive directory path entry can be an absolute or relative path. |
||||
|
Polling: This section contains parameters that are used for optimization of the bulkstatistics module in terms of polling.
|
||||
 Important: This value should not be greater than the MaxDbConnPool parameter defined in the etc/db.cfg file. |
||||
|
Queue: This section contains parameters that are used for optimization of the bulkstatistics module in terms of queuing.
|
||||
|
DBSession: This section contains parameters that are used for optimization of the bulkstatistics module for database calls in terms of DB sessions.
|
||||
|
Parser: This section contains parameters that are used for connection to the Parser Server process.
|
||||
Important: Any change in the configuration files will restart the server resulting in client restart.
Caution: Several parameters contained in this file are configurable through the installation process.|
Port: This section contains the server port to which the BulkStat server binds.
|
||||
|
Interval: This section contains the interval parameters for polling operations.
|
||||
|
Thread Pool: This section contains the configuration values for the thread pool.
|
||||
|
Access TIme: This section contains the configuration values for overriding the bulkstat XML measurement generation timestamp.
|
||||
|
XML Data: The following values are the default data values for the XML Measurement file for the 3GPP recommended XML nodes. For more information, refer to the 3GPP TS 32.401 V4.1.0 (2001-12) document.
|
||||
|
BSFTP: The bulkstat server transfers the generated XML file to NM using FTP. This section defines the default values for FTP.
|
||||
|
UNKNOWNURL: This section displays unknown URL database files Import interval related information.
|
||||
|
Reports: This section displays the report related information.
|
||||
|
This specifies the maximum number of reports that can be present in the reports/cf/ directory.
|
||||
Important: Any change in the configuration files will restart the server resulting in client restart.|
CFBackupArchiveDatabase: This section contains the config variables related to archive operation of various CF databases.
|
||||
|
ArchivePath = ./flash/archive/
|
||||
Important: Any change in the configuration files will restart the server resulting in client restart.|
If the specified directory does not exist, then the config files will be stored in ./flash/ConfigUpdate/log.
 Important: The config file directory path entry should always be an absolute path and not a relative path. |
||||
|
If the specified directory does not exist, then the config files will be stored in ./flash/ConfigUpdate/config.
 Important: The config file directory path entry should always be an absolute path and not a relative path. |
||||
Important: Any change in the configuration files will restart the server resulting in client restart.
Caution: Improper configuration of this file can adversely affect WEM operation. To ensure proper operation of the Web Element Manager, do not edit the parameters in these files.
 Important: Any change in the configuration files will restart the server resulting in client restart. |
||||
|
PostgresDIR = /<ems_dir>/postgres
|
|
License: This is the WEM License file.
|
|||
|
SEVERITY: This section describes the severity configuration for traps that contain various priorities and the color in which the traps of that severity should be displayed.
|
||||||||
|
EMAIL: This section describes the E-mail configuration for traps.
|
||||||||
|
SCRIPT: This section describes the script configuration for traps.
|
||||||||
|
TRAP: This section describes the flags for logging traps.
|
||||||||
|
||||||||
|
SYSLOG: This section describes the Syslog server configuration for traps.
|
||||||||
|
CLIInfoPolling: This section provides information needed for the configuration of Thread pool and Polling interval required for the FMCliInfoHandler module.
|
||||||||
 Important: These value are dependent on the keepalive notification interval. |
||||||||
|
PENDINGALARM: This section describes the pending alarm related configuration.
|
||||||||
Important: The parameter in this file is configurable through the installation process.|
HWEMAIL: This is the configuration file for Hardware Inventory.
|
||
Important: Any change in the configuration files will restart the server resulting in client restart.|
IMGSessMgt: This section describes the parameters that store ASR 5000 login information.
|
||||
|
Change the value of ENFORCE_SSL parameter in ems/client/img.html and ems/client/imgdebug.html if this value is changed. If set to 1, then the sslflag field will be updated to 't' for all existing IMGs in the boxer table in ConfigDB at server restart.
|
||||
|
IMGKeepAlive: This section describes parameters related to the ASR 5000 keep-alive.
|
||||
 Important: The value must be greater than IcmpTimeout * (IcmpRetries + 1). |
||||
 Important: The value must be greater than or equal to IcmpKeepAliveInterval. |
||||
|
MCRDBS: This section describes parameters that store MCRDBS related information.
|
||||
 Important: If the user does not want to enter any values, leave the fields blank separated by comma. |
||||
Important: Any change in the configuration files will restart the server resulting in client restart.|
Fault Management: This section describes the parameters that store NorthBound Notification Service related configuration information.
|
||||
Important: The NorthBound Server and Notification Service processes are customer-specific and are not operational without the appropriate license. Please contact your local sales representative for additional information.
Important: Many of the parameters contained in this file are configurable through the installation process.|
DATABASE: This section describes parameters that store database configuration information.
|
||||
|
ClientSession: This section describes parameters related to client session management.
|
||||
|
SWUpgrade: This section describes the parameters related to Software Upgrade.
|
||||
|
FRV: This section describes the front/rear-view related parameters.
|
||||
|
POAPolicies: This section describes policies used for the POAs.
|
||||
|
EMSORB: This section describes the parameters related to Object Request Broker.
|
||||
|
MPEManagerInfo: This section provides information required to configure the details of MPE Manager making the HTTP Post request.
|
||||
|
PCRFFTP: The pcrfrepgen process transfers the generated 3GPP XML file to NM using ftp. This section defines the default values for ftp.
The pcrfrepgen process uses the same host machine used by the bulkstat server for transferring the GGSN files. FTP configuration parameters 'HostIPAddr', BSFTPUserName', 'BSFTPPassword', 'BSFTPMaxRetries', 'BSFTPRetryInterval' and BSUseSFTP' from /etc/bsserver.cfg will be used to transfer the generated PCRF 3GPP XML files.
|
||||
Important: Any change in the configuration files will restart the server resulting in client restart.|
Polling: This section describes the parameters related to polling support.
|
||||
|
Database: This section describes the parameters related to database information.
|
||||
 Important: Psmon will never attempt to kill a process ID lesser than or equal to 1, or itself. |
||
 Important: Read the config file thoroughly before enabling this feature. |
||
|
Note: Do not remove the following statement as it is used to modify the config file while installing through the GUI Installer:
|
||
Important: Any change in the configuration files will restart the server resulting in client restart.
Caution: To ensure proper operation of the Web Element Manager, do not edit the parameters in these files.
Important: This configuration file is customer-specific and is not operational without the appropriate license. Please contact your local sales representative for additional information.
Caution: To ensure proper operation of the WEM, do not edit the parameters in these files.|
THREAD: This is the configuration file for Thread pool.
|
||||
Important: Any change in the configuration files will restart the server resulting in client restart.|
Security: This file contains the list of security parameters for user access to WEM.
|
||||||||
|
||||||||
|
Type: This section describes the type of vacuum to be done on database.
|
|||||
 Important: VACUUM FULL is not recommended for routine use. |
|||||
 Important: It is not recommended to start table level vacuuming for all tables at the same time as it will increase number of transactions to the database. Database level vacuuming takes care of table level vacuuming, that means it vacuums whole database including all the tables present in that database so at critical point if we want to start vacuuming on all tables at the same time, at that point, we can start only database level vacuum. If we want to vacuum one or more (but not all) tables from the database, in that case we can use table level vacuuming by enabling vacuum for that tables. |
|||||
|
WBLIST: This section describes the parameters that store Content Filtering Server information.
|
|
|
WblistPath = ./flash/cf/cfdatabases/wblistdb/
|
|
Appendix D
XML Output Formats
XML Output Formats
Important: Unless otherwise specified, all information in this chapter applies to both Sun Solaris- and Red Hat Enterprise Linux-based WEM systems.|
•
|
DTD Based Format: This format is DTD based and it can be enabled/disabled using the configurable parameter, ‘XMLFileFormat’ provided in the configuration file bsserver.cfg in the /<ems_dir>/etc directory.
|
|
•
|
3GPP Format: This is the new and default 3GPP recommended format to generate the XML report file. This format reduces the XML file size.
|
|
•
|
3GPP TS 32.401 V4.1.0 (2001-12): “Concept and Requirements”
|
|
•
|
3GPP TS 32.435 V6.2.0 (2006-03): “Performance measurement: eXtensible Markup Language (XML) file format definition”
|
Important: A bulk statistic type of 'Counter' is referred to as an 'Incremental Counter' in WEM files.
Important: WEM must be able to reference two consecutive bulk statistics collection records before it can generate an XML report. If two consecutive records are not found, WEM does not generate a report. |
100 (200-100=100)
|
|||
|
200 (400-200=200)
|
|||
|
600 (1000-400=600)
|
|||
|
500 (1500-1000=500)
|
